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(54) Abstract Title 

Personal conferencing system 

(57) There is described a personal conferencing method and system for a client (32)/server (30) environment. 
The server (30) stores conference model data (60) such as a shared chalkboard or a molecular model and each 
client has a copy of the conference model data (60). When one of said clients (32A, 32B, 32C) edits the model 
(60) it creates an instruction (64D) for operating on the model and sends the instruction <64A) to the server (30). 
The server (30) operates (62) on its conference model data (60) on receipt of the instruction (64A) and resends 
the instruction (64B) to each of the clients (32A, 32B, 32C) and each client (32A, 32B, 32C) performs the same 
operation (62) on their respective copies of the conference data model (60). Whereby after a plurality of 
different operating instructions (64B) from different clients (32A, 32B, 32C) the respective copies of the 
conference model data (60) are equivalent. 
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PERSONAL CONFERENCING SYSTEM 



23241 75 



This invention relates to a personal conferencing system. 

Personal computer conferencing allows a computer user to 
participate in a meeting from his own desk instead of travelling to a 
location mutually convenient to all parties. Just as telephony systems 
have developed to include conference calls to more than two parties so 
have computer systems developed to allow large numbers of networked 
computer users to participate in a single conference. An example of 
personal conferencing is an internet 'chat room' in which one can conduct 
meetings in text or voice in real time with other computer users. 

A development of the 'chat room' type conference is the application 
type conference in which Personal Conferencing systems try to allow a 
number of participants to share applications so that they can all 
interact with them and see the same results. One example of this is the 
'white board ' application in which participants can draw on a 'common' 
white board and see and edit the same drawing. Another example is -a 
molecular modelling application in which each participant may change and 
manipulate a molecule displayed on the computer screen. <g> 

Some Personal Conferencing Systems are implemented in a peer-to- 
peer fashion. An example of this are the PM2PM and Person to Person/2 
products developed by IBM Corporation. In this environment, for example 
(see Figure 1) a conference management /call manager program (18A, 18B) 
runs in each computer (10A, 10B) drawing upon the services of one or more 
network adaptors (12A, 12B) to communicate over a network (14) . A number 
of specially written personal conferencing applications (16A, 16B, 16C) 
connect to the conference management. If a conference includes a shared 
chalkboard, for example, then on each participating node chalkboard 
personal conferencing applications (16A, 16B, 16C) will be running. 
These applications send packets of data to each other, utilising the 
services of the conference management program (18A, 18B) . 



This arrangement has the following drawbacks: 
(i) As the conferencing management program is not responsible for 
ensuring that the data in the application on each node 
corresponding to the same shared chalkboard (or other data} 
is the same, the applications must invent and use a protocol 
between them for doing so. 
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(ii) Each node may elect to not store an entirely identical copy 

of the data which its peers do. This design decision is often made 
in error, as it tends to expedite a rapid implementation, with the 
side effects not being immediately apparent. 

(iii) If a new participant joins the conference, then a copy of the 

data in the chalkboard (or other data) must be transmitted from one 
of the nodes. If the data on each node is not identical, then 
which data is best sent? For an efficient transfer, the 
application may need an appreciation of the network geography, 
further complicating the implementation of the application. When a 
new participant joins the conference, and wishes to share an 
existing application he must be brought into step. 

(iv) All this extra complication in the applications (peer-to-peer 
protocol to keep data in step, joining and leaving transfer, 
knowledge of geography) must be duplicated in each sort of 
application. 

(v) A person may not indicate their readiness to participate in a 
conference on their own, as there is no 'meeting point' 
inherent in the system. There is no server which can 
reasonably expect to be powered up at any time, in a purely 
peer-to-peer system. 

An example of personal conferencing which does not allow 
manipulation of shared data by either party, is simplified Peer-to-Peer 
such as the shared whiteboard application in the NeWI environment 
developed by Data Connection Limited. The whiteboard has multiple 
planes, one per participant. Each participant can draw upon his own 
plane, and changes to his plane is transmitted to the other participants, 
who can then see (but not change) the new plane. As nobody can change 
the picture on the plane of another, there is no shared manipulation of 
shared data. 'NeWI' is a trademark of Data Connection Limited. 

Simplified Peer-to-Peer has further disadvantages. Although in the 
example of a shared whiteboard some utility is afforded by such a tool, 
most of the value is in the shared manipulation of data. Although this 
system is simple to implement, this style of 'conferencing' is awkward 
for text editing and other forms of shared manipulation. 

One of the main problems of peer-to-peer conferencing systems is 
therefore that of serialisation, the requirement that all the data must 
arrive at all the destinations/nodes in the same order to preserve the 



, • . The order used is normally the order in 

conference model integrity. The oraer us 

which the data is sent. 

A different type of personal conferencing is provided by the XTV 
A differenc ryp enhancement /modification 

; system developed by IBM Corporation. This is an enh kevstrokes 

of the XWindows system. If the input events (mouse-clicks, keystrokes 
etc.) from a variety of participants can he transmitted to a given 
machine, applied to a running program, and the resulting change to the 
screen (or windows of the program) transmitted back to the participants, 
D a rudimentary form of personal conferencing can be achieved. 

XWindows is a client-server system, whereby the servers serve the 
ability to provide user input, and also serve the ability to draw to 
their screen. Typically each user has an Xserver (20) running on their 
machine and the data-stream is sent to the Xserver (20) via an XTV 
interceptor (22) to get it to display graphics using X-protocol . As 
XWindows is client-server, and X-protocol is transmitted between them, it 
is usual for clients and servers to be running in different machines. 
XWindows implies networking, and this is handy when collaborative working 

■0 is desired (as in personal conferencing). For output, XTV (22) 

intercepts the X-protocol sent by an application running on a client (24) 
to a server (26, . It fans this data out to a number of Xservers (20), 
thus making the programs windows visible to a number of participants. 
Similarly, input is drawn from a number of Xservers (20), and channelled 

IS in to the machine running the shared (multiply accessible) application. 

XTV and XWindows are trademarks of IBM Corporation. 

Normal XWindows client-server interaction is shown in Figure 2A and 
Interaction with XTV (22) 'in the middle' is shown in Figure 2B. XTV 
30 (22) routes input and output traffic between a number of applications and 

servers and has the advantage of working with all existing non- 
collaborative applications. 

However, it has the following drawbacks: 
35 ( i) its not a collaborative application 'enabler'. 

(ii) Non-collaborative applications are written with one user in 
mind and keystrokes and mouseclicks are from a variety of users, 
all interleaved in time. 

(iii) All users can only see an identical view of the data. egtUser 
40 one cannot see a roomed view of the chalkboard, whilst user 

two sees the normal size. 



(iv) Changes to the application data can result in large quantities of 
screen changes (and thus X-protocol) , and this problem is made 
worse by the fact that it is now sent to all the participants. 

(v) The application is really only running on one machine, and so 
5 the data it holds is only accessible on that machine unless 

all the machines share a common file-system (such as AFS or 
DFS) . Even if machines share access to a common file-system, 
drive letters and pathnames may be different across machines, 
for the same file. Generally, when manipulation remote data, 
10 you (the user) have to consider that you are running on the 

remote machine. This is added complexity for the user. 

Another problem of most types of Personal Conference system is that 
no attempt has been made to optimize the network performance by choosing 
15 the nearest (network speed wise) existing participant to the new 

participant. Commonly, personal conference systems have transmitted the 
data from an arbitrary existing node to a new node. 

EPO497022 Hewlett-Packard relates to a distributed object-based 
20 computer system in which sharable objects are split into client and 

server components. It is designed for a number of servers which 
communicate amongst themselves to send messages and deliver updates. 

The embodiment of the invention draws on a number of disciplines 
25 for its performance. One of these Model /View/Controller (or MVC for 

short) is a discipline used in implementing applications. Such an 
application is divided up into three logical parts, with clearly defined 
interfaces and responsibilities. 

30 The Model is the data which the application is presenting and 

allowing to be manipulated. However the Model itself only contains the 
data and entrypoints (ie: methods) by which the data may be changed. The 
Model has no concept of how the data is to be presented to the user, and 
no concept of how a user indicates or is allowed to specify their 

3 5 intended change/modification of the data. In the example of a Chalkboard 

application, the Model could be a bitmap representing the picture. The 
Model would not include any concept of a current pen colour, fill style 
or font setting etc. Modification of the data in the Model is achieved 
through the entrypoints /methods , and the new state of the Model is 

40 determined entirely from the old state and the parameters to the 

entrypoint (ie: the entrypoints are pure, and do not use global data) . 



In this description the entrypoints /methods are associated with operating 
on the data of the model or the 'means for operating'. 

The View is the user-interface components for showing the user the 
current state of the Model. It determines how to display the model 
purely from the Model data it is configured to show, with access to no 
external or global variables. That is to say that given a particular 
Model, you will always get the same visual representation. In the 
example of a Chalkboard application, the View might chose to display the 
Models bitmap in the client area of a window, with scrollbars. 

The Controller is the user-interface components for allowing the 
user to specify changes to the Model. In the example of a Chalkboard 
application, the Controller is responsible for showing the rubberbanding 
which occurs when the user decides to draw a rectangle (or other graphic 
symbol) on the Chalkboard. The Controller does not directly modify the 
Model (eg: draw the rectangle) - rather it calls entrypoints in the Model 
to get this job done. The Controller can maintain the users current 
choice of pen colour and font, and this information is passed as a part 
of a draw-rectangle command passed to the Model (in order that the .change 
be completely specified) . In this description the controller is 
associated with the creation of an operating instruction or the means for 
creat ing . 

In the interests of efficiency, when a Model has changed, it may 
notify the View (or Views) of itself of the fact that it has changed, and 
perhaps the extent of the change. This allows the View to redraw itself 
to reflect the change, or even to selectively redraw the part of itself 
that has been affected. 

In practice the distinction between Controller and View is often 
blurred. In the case of the Chalkboard, the same client window might 
both display the current View of the bitmap and the rubberbanding taking 
place due to the current user interaction with the Controller. 

The embodiments of the present invention attempt to address these 
and other problems. 

A personal conferencing method for a server computer (30) having 
one or more client computers (32A, 32B, 32C) connected comprising the 
steps of : 




(a) 
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l30> ' (b) operating (.» on the „odel data (60, on receipt 

o£ ,„ Instruction ,.«» «~ • •«-<• colter, (jq) 
(c) resending the instruction (64B) from tn 

f^?A 32B, 32C) whereby each client 
to each of the client computers (32A. 32B, 

computer (32,, 32B, 32C, performs the same operation (62, on a copy 
the conference data model held on the client computer so that a the 
copies of the conference data model (60) correspond to the conference 
model data held on the server computer. 

^nfinuration for a conferencing system in 
Usina a client/server configuration 

rather than the client has clear » ™*^° lS " 

" provide which is H-Ul for any <„on- b roh.n, person.! =o„ £ ere„ce 
!y ,L aesign. All editing usages pass through the server computer. 
US „ey to the client computes, thereby providing « central 
eeri.lLtion point. The serv.r ccput.r =,. promise to del>ver data to 
In client counters in the sa»e order wh.ch guarantees that ail clr.nt 
computers display the same thing. 

^rther advantages are apparent. For instance, the design of a 
personal conferencing system is formalized and simplified through 
incorporating a Model/View/Controller configuration. Also ^~ce P ting 
changes to the conference model and distributing the change to the client 
computers is the simplest way of achieving corresponding screen views^ 
in such a design the server computer is free of any user interface code. 

The server computer itself provides a permanent 'meeting point', 
where clients can advertise their existence and willingness to 
participate in shared work. This advantage is particularly lacking m 
peer-to-peer systems. 

According to a second aspect of the present invention there is 
provided a personal conferencing method for one or more client computers 
connected to a server computer comprising the steps of: 

(a) each of said client computers storing a copy of conference 

model data; 

(b , one of said client computers creating an instruction for 
operating on the conference model data and sending said instruction to 
the server computer; 




(c) each of said client computer, receiving a copy of the 
instruction fro, the server computer and operating on their respective 
models according to the instruction; 

whereby after a plurality of different operating instructs fro, 
different clients the respective copies of the conference model data 
correspond with each other . 

According to a third aspect of the present invention there is 
provided a personal conferencing system comprising at least two clxent 
computers and a server computer; 

the server computer comprising: 

conference model data; 

means for receiving an instruction from a client computer and 
operating on the conference model data according to the instruction; 
the client computer comprising: 

means for creating an instruction and sending the instruction to 

the server computer; 

characterised by: 

the server computer further comprising means for dispersing a,,, 
received instruction to all the client computer; and 

each of the client computers further comprising: 
a copy of the conference model data; 

means for receiving a dispersed instruction from the server , 
computer and operating on the copy of the conference model data according 
to the instruction received from the server computer. 

f 

According to a fourth aspect of the present invention there is 
provided a personal conferencing system comprising at least two computers 
connected for message communication; each computer comprising: 

conference model data; 

means for creating an instruction for operating on the conference 
model data and sending the instruction to another computer; 

means for operating on the conference model data according to an 
instruction; 

characterised by: 

one of the computers is a server computer and the other computer or 
computers are client computers, each having a connection to the server 
computer ; 

the server computers further comprises a means for dispersing a 
received instruction to all the connected client computers; and 
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the means for operating comprises means for receiving a dispersed 
instruction from the server computer; 

whereby a sequence of operating instructions from different 
computers in the personal conferencing system will be performed in the 
5 same order on each copy of conference model data. 

A personal conferencing system comprising: 
a server object and a plurality of client objects; 
a model object (3 6A) having model data (60) and means (62) for 
10 operating on the model data (60) to an instruction message (64B); 

each client object (36) having means (36B) for creating an 
instruction for operating on the model object (36A); 
characterised by: 

each client object (36) comprising an associated model object 

15 (36A); 

each client object (36) further comprises means (36B) for passing 
an operating instruction to the server object; 

said server object (50) further comprises means (50B) for 
dispersing a passed instruction from the server object to all client 
20 objects (36) ; 

thereby allowing a sequence of instructions from different client 
objects (36) to be performed in the same order by each model object on 
each instance of the model data (60). 

25 Preferably the instruction is in the form of an Opcode having 

arguments. This is a convenient way of packaging modifications to the 
conference model data so that the modifications may be easily distributed 
from the client computer creating it to the server computer and from the 
server computer to all the client computers involved in the conference. 

30 Clearly if the same initial conference model data exists on a number of 

client computers, applying the same operation to all the copies of the 
conference model data will result in the same model. 

Preferably the server computer sends a copy of the conference model 
35 data to a client computer who wishes to join the conference and makes 

such a request to the server computer. This enables new client computers 
to join the conference at any point and to receive an accurate and 
reliable copy of the conference proceedings at that point. In a 
preferred embodiment a blank template conference model is stored on the 
40 client computer and its state is changed to match the state of the 

conference model data held in the server. 




in the preferred embodiment the methods that are performed in the 
server computer and the client computers are under the control of a 
hosted byte code such as JAVA . This allows cross platform portability of 
a conference. It is advantageous that the machine hosted byte code is 
downloadable from the server computer by a network browser running on the 
client computer. This allows easy connectivity by most computers already 
connected to' the internet by real time downloading from the World Wide 
Web without the need for any pre-installed client code. 

In the preferred embodiment each client computer graphically 
displays the conference model data on a computer screen. Each client 
computer may therefore adapt the particulars of the way in which the 
conference model data is displayed on its own screen, i.e. the view, 
while at the same time displaying the same conference model data as each 
of the other client computers. 

In the preferred embodiment the server computer does not need to 
graphically display the conference model data but has a central role in 
the conference with responsibility for maintaining all the copies of the 
conference model data on the client computers. Centralised conference 
model data on the server computer may act as master and force all .the 
client computers to be kept in step. 

Hosted machine code is a platform independent code such as the byte 
code needed for the JAVA Virtual Machine. Hosted machine code such as 
JAVA byte code provides operating system/platform independence of , 
applications and JAVA byte code is a programmable code that is executable 
on any JAVA enabled platform (an operating system having a JAVA 
executable environment or virtual machine) without recompilat ion . JAVA 
is a trademark of SUN MICROSYSTEMS CORPORATION. 

In order to promote a fuller understanding of this and other 
aspects of the present invention, an embodiment will now be described, by 
way of example only, with reference to the accompanying drawings in 
which : 

Figure 1 is prior art example of a peer to peer conferencing 
system; 

Figure 2 is a prior art example of a cl ient /server conferencing 
system; 

Figure 3 is a schematic representation of the embodiment of the 
invention; 
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Figure 4 is a schematic representation of the program classes used 
to implement the embodiment of the invention; and 

Figure 5 is a representation of the computer screen for IBM's 
Teamworker application. 

A client /server arrangement of the embodiment of the invention has 
a central server computer (30) connected directly to three client 
computers (32A, 32B, 32C) (see Figure 3). A client computer (32A) 
comprises a processor (34) which performs- under the instruction of client 
code (36A, 36B, 36C) (client program code) stored in memory (38) and/or 
on disk of a client computer. Visual output of the client computer (36A) 
is through a video peripheral (40) such as a monitor or LCD screen 
connected to the processor (34) and user input to the client computer 
(32A) is by a keyboard (42) and computer mouse (43) connected to the 
processor (34). The client computer further comprises a network adaptor 
(44) connected to the processor at one end and a computer network (46) at 
the other. Examples of two computer networks (46) are a corporate 
intranet and the internet. Examples of the client computer is IBM's 
Aptiva computer having a 486 133Mhz micro processor, 1Gbyte hard drive, 
16Mbytes of memory and a 16 inch monitor. 

The server computer (30) comprises a processor (47) which performs 
under the instruction of server code (50A, SOB) (server programme code) 
stored in memory (52) and/or on disk of the server computer. Visual 
output is not strictly necessary but may be through a video peripheral 
such as a monitor or LCr screen connected to the processor (48) and user 
input is also not strictly necessary but would be through a keyboard or 
computer mouse connected to the processor (46). The server computer (30) 
further comprises a network adaptor (54) connected to the processor (48) 
at one end and the computer network (46) at the other. An examples of 
the client computer is IBM's RISC6000 computer having a Intel P200Mhz 
micro processor, a 20Gbyte hard drive and 64Mbytes of memory. 

Each instance of client code (36A, 36B, 36C) comprises three main 
parts: the conference model object (3 6A) (an instance of a 
ConferencingAppletModel class), the conference controller object (36B) 

(an instance of a Conf erencingApplet Controller class) and the conference 
view object (36C) (an instance of a Conf erencingAppletView class). The 
client code forms a client applet (56) which is contained within a World 
Wide Web page (58) stored on the server. There are as many instances of 

client code (36) as there are client computers (32A, 32B, 32C) and an 
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instance of the client code is downloaded and stored on each client 
computer (32A, 32B, 32C) . 

To download or create an instance of client code on a client 
computer (32A) a computer having a JAVA enabled web browser connected to 
the internet is required; on accessing and viewing a conference web page 
(58) containing a client applet (56) the browser will copy the client 
applet (56) on to the client computer (32A) . The applet (56) will 
normally execute upon download but may also execute after performing an 
event such as selecting a button icon displayed on the monitor (40) using 
the cursor and mouse (43) . 

The server code (50A, SOB) comprises two main parts: the conference 
manager object (50A) (an instance of a Conf erencingSystemManager class) 
and the conference model object ( SOB) (an instance of the 
ConferencingAppletModel class). Other server objects used in the server 
code are: a ServerMain object (50C) ; a Connection object (SOD); and a 
ServerMonitor object (50E) (see Figure 4). 

The ServerMain object (50C) listens for and accepts incoming* 
network connections from clients. When a connection is received it 
creates an instance of the Connection class (SOD). The ServerMain object 
also creates and owns a single Conf erencingSystemManger object. 

An instance (50B) of the Connection class is created whenever a 
network connection is accepted by the server so that for each client a 
Connection object exists. It represents a connection to an individual 
client. The Connection object (50D) runs a thread which continually 
listens for incoming messages from the client and passes them onto the 
Conf erencingSystemManager class. The Connection object (50D) is also 
used for sending messages from the Conf erencingSystemManager (SOB) back 
out to the client. 

The Conf erencingSystemManager object (50B) is the object that 
manages concurrent multi-party conferences for the server. Each 
conference in progress is represented by an instance of the 
ConferencingAppletModel class (or to be precise, one of its subclasses) . 
Each conference in progress identifies its model class by a "model id" 
which is passed on all messages. 
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The ServerMonitor object (50E) provides a graphical view of the 
activities of the Conf erencingSys teenager (SOB). It can be used by an 
administrator to monitor activity in the conferencing system. 

The ConferencingAppletModel class (50A) is the superclass for all 
conference models. Each type of multi-party conference introduces its 
own subclass of ConferencingAppletModel. For example, there might be a 
ChatConferenceModel for chat applications, a ChalkboardConf erenceModel 
for chalkboard applications and so on. The model object maintains the 
current state of the conference in the form of model data (60). It 
provides three important methods: 

* applyOpCode ( ) (62) - applies an operand and its arguments (as 
received in a message from a client), to the model, which will cause the 
model's data (60) (state) to be updated. 

* setStateO - causes the model to set its data (60) (state) to 
that passed in the message 

* getStateO - causes the model to generate a message containing 

its current state 

Other client objects used in the client code are: a Sharer object 
(36D) and a SharerReader object (36E) (see Figure 4). 

The ConferencingAppletModel object (36A) is the same object as used 
in the server, with subclasses as described above. 

The ConferencingAppletView class is the superclass for all 
conference views (used to display the current state of the conference to 
the user - eg. the appends in a chat conference) . Each type of 
conference introduces its own subclass of ConferencingAppletView. A view 
class instance (36C) is on one-to-one correspondence with a model. When 
the model's data (60) changes, it calls the ■ invalidate () - method of the 
view which causes the view to redraw itself. 

The ConferencingAppletController class is the superclass for all 
35 conference controllers (used to send messages to and read messages from 

the server) and forms a controller object (36B). Each type of conference 
introduces its own subclass of ConferencingAppletController. A 
controller object (3 6B) is in one-to-one correspondence with a view and a 
model. When user actions are initiated at the end-user interface, the 
view informs the controller of the action to be taken. The controller 
builds this into a message and sends it to the server (30) . The server 
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(30) then broadcasts the message to all controllers in the conference. 
L ikewise, the controller listens for incoming messages from the server 
and passes the, to the model's applyOpcode ( ) method (62) for evaluate. 

The Sharer object (36D) is used by the Conf erencingAppletController 
to establish a socket connection with the server, and then to send 
messages to it. 

The SharerReader object (36E) is used by the 
ConferencingAppletController to listen for incoming messages from the 
server (30) and pass them to the model for evaluation. 

The initialisation of the embodiment is as follows. The client 
computer (32A) under the control of a World Wide Web browser is 
instructed to view a page (58) containing the client applet (50). The 
page (58) may be meeting point for users wishing to participate in a 
certain type of conference. Upon viewing, the client applet (56) is 
downloaded to the client computer from the server (30) and when executed, 
instances of the client code are created including a 

ConferencingAppletModel object (36A) , ConferencingAppletController object 
(36B), ConferencingAppletView object (36C), Sharer object (36D) and,.. 
SharerReader object (36E) . The client computer (32A) under the control 
of the Sharer object (36D) then attempts to establish a socket connect 
with the server object. 

The server code (50A to 50E) for a particular conference is created 
as soon as a first client requests a connection for a conference that 
does not exist. When subsequent client computers attempt to establish a 
socket connection the ServerMain object (50C) creates an instance of the 
Connection class (SOD) and associates it with that client computer. The 
ServerMain object (50C) determines the state of the model data (60) in 
the ConferencingAppletModel object (50A) by calling the getState (state) 
method which creates a message containing the (state) . This message is 
sent by the Connection object (50D) in the server through the network 
connection to the client object (36A) where it is picked up by the 
SharerReader object (36E). The message is then passed on to the client's 
ConferencingAppletModel object (3 6A) which changes the state of its model 
data (60) to that sent in the message using its setState (state) method. 

Once a client computer stores a current model data (60) it receives 
a constant flow of update messages comprising operation codes (Opcode) 
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from the server (50A to 50D) requesting the conference model object (36A) 
to update itself using the applyOpCode (OpCode ) method (62). The update 
messages continue as long as the conference is in progress. The server 
in fact sends the same update message (OpCode) to each of the clients 
connected for a particular conference. In this way, if all the 
conference model objects have the same model data at the start and 
receive the same message updates (OpCode) in the same sequence then, at 
any point in the conference, the model data (60) of any conference model 
object will match. 

If a client wishes to partake in the conference by adding or 
editing the model data (60) then the changes to the model data (60) are 
expressed as an operation code by the conference controller object (36B) 
and sent to the conference manager object (50B) in the server computer 
(30). The conference manager object (50B) then disperses or resends the 
operation code as an update message to all the partaking client objects 
(36) . Each conference model object (3 6A) receives the update message and 
each applyOpCode method (62) updates the each respective set of model 
data (60) . 

The conference model object (50A) of the server (30) also receives 
the update message and the applyOpCode ( ) method (62) update the server 
object's model data (60). 

An embodiment of the invention is IBM's TeamWorker application 
developed for a corporate intranet as an interactive team working 
environment. The model data (60) is the data used in a chalkboard 
application representing a two dimensional surface which may be written 
or drawn or painted on in many colours. Figure 4 shows the interaction 
between the main classes in TeamWorker. The other classes in TeamWorker 
are used to implement particular conferencing applications on top of the 
TeamWorker infrastructure, and to provide a graphical front end from 
which those conferences can be launched. 

The main applet class (56) that is executed when it is downloaded 
to a browser. It creates the TeamWorkerWindow used to display the 
conferencing facilities to the user Figure 5. TeamWorker has a concept 
of a "team", and each member of the team is represented by an instance of 
the TeamMemberModel class inside the applet. Every TeamMemberModel has a 
corresponding TeamMemberView which represents that team member within the 
main window by displaying their picture in a passport photograph sized 
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window. To the left of the team members photos, a toolbar is displayed 
which allows the user to launch conferencing facilities. Each 
conferencing facility available is represented by a button in the 
toolbar. These buttons are implemented by the classes ChatButton (whxch 
is used to start or join a multi-party chat conference, DiaryButcon 
(which is used to display a team members dxary) . EMailButton (which xs 
used to send e-mail to a team member), HomePageButton (which requests the 
web browser hosting the team worker applet to display the team members 
home page), MessageButton (which is used to send a direct message - pops 
up on the recipients display - to another team member), PhoneButton (used 
to display another team members phone number) , and JoggleButton (which 
launches a multi-party game called Joggle) . 

Some of these facilities are implemented purely by the client (for 
example the display of the phone number and home page), and others are 
true multi-party conferencing applications that require the team worker 
infrastructure that is the subject of the application. 

When one of the conference buttons is pressed (for example, the 
chat button), new Conf erenceView (36C) , Model (36A) and Controller (36D) 
instances are created to manage the conference. The actual classes 
created are subclasses of the Conf erencingAppletModel , View and 
Controller classes that are particular to the given type of conference. 
In this case we would create instances of the. ChatConf erenceModel , View 
and Controller classes. These classes are used to manage the chat in the 
manner previously described and illustrated in the Figure. 

The invention is not restricted to chalkboard applications, another 
embodiment of the invention could be a three dimensional molecular 
modelling application as used by chemists and biologists and in which the 
use of the invention would be particularly advantageous. The model data 
(60) may represent the types, positions and connections of various atoms 
in a molecule. The conference view object would be able to view the 
molecule in any orientation and the conference controller object would 
allow the user to manipulate and change the atoms. Such an application 
is particularly processor intensive due to the high resolution images use 
and the model data (60) needs to be quickly accessible to the client 
computer and storing the model data on the client computer is the main 
practical solution. This leads to the problems outlined in the 
introduction to the specification which the application addresses. 
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Due to the nature of programming it is quite possible to implement 
the invention using a programming language other than an object 
orientated programming language. 

In the object orientated environment it is possible for the a 
client computer to participate in more than one conference. 

Of course the server computer may in fact be connected to any 
number of client computers not just three as stated in the example. 
Further it is not necessary to use the computers given as examples as the 
invention may be performed using other types of computer connected in 
different configurations. 

In summary there is described a personal conferencing method and 
system for a client/server environment. The server stores conference 
model data (60) such as a shared chalkboard or a molecular model and each 
client has a copy of the conference model data (60). When one of said 
clients edits the model it creates an instruction for operating on the 
model and sends the instruction to the server. The server operates (62) 
on its conference model data on receipt of the instruction and resends 
the instruction to each of the clients and each client performs the same 
operation (62) on their respective copies of the conference data model 
(60). Whereby after a plurality of different operating instructions from 
different clients the respective copies of the conference model data (60) 
are equivalent. 
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17 
CLAIMS 



1 A personal conferencing method for a server computer (30) having 

one or more client computers (32A. 32B, 32C) connected comprising the 
5 steps of: 

(a) storing conference model data (60) on the server computer 

(30); 

10 (b) operating (62) on the conference model data (60) on receipt 

of an instruction (64A) from a client computer; 

(c) resending the instruction (64B) from the server computer (30> 
to each of the client computers (32A, 32B, 32C) whereby each client 
15 computer (32A, 32B, 32C) performs the same operation (62) on a copy of 

the conference data model held on the client computer so that all the 
copies of the conference data model (60) correspond to the conference 
model data held on the server computer. 

20 2. A personal conferencing method for one or more client computers 

(32A, 32B, 32C) connected to a server computer (30) comprising the steps' 
of: 

(a) each of said client computers storing a copy of conference 
25 model data (60) ; 

(b) one of said client computers (32A) creating an instruction 
(64A) for operating on the conference model data (60) and sending said 
instruction (64A) to the server computer (30); 



(c) each of said client computers (32A, 32B, 32C) receiving a 
copy of the instruction (64B) from the server computer and operating (62) 
on their respective models (60) according to the instruction (64B); 

whereby after a plurality of different operating instructions (64B) 
from different clients the respective copies of the conference model data 
correspond with each other. 



40 



3. A method as claimed in claim 1 or 2 wherein the server computer 
sends the conference model data (60) to a client computer on request. 




4. A method as claimed in claim 1,2 or 3 wherein the steps are 
performed under the control of machine hosted byte code. 

5. A method as claimed in claim 4 wherein machine hosted byte code for 
controlling a client computer (32A, 32B, 32C5 is downloadable from the 
server computer (30) by a network browser running on the client computer 
(32A, 32B, 32C) . 

6. A method as claimed in any of claims 2 to 5 wherein said 
instruction (64A) to operate of the conference model data is in the form 
of an Opcode with arguments. 

7. A personal conferencing system comprising at least two client 
computers (32A, 32B, 32C) and a server computer (30); 

the server computer (36) comprising: 



conference model data (60); 

means (50A, 62) for receiving an instruction from a client compute 
and operating on the conference model data according to the instruction; 

the client computer (32A, 32B, 32C) comprising: 

means (36B) for creating an instruction and sending the instructic 
to the server computer; 



characterised by. 

the server computer further comprising means (50B) for dispersing a 
received instruction to all the client computer (32A, 32B, 32C) ; and 

each of the client computers (32A, 32B, 32C) further comprising: 



a copy of the conference model data (60); 

means (3 6A, 62) for receiving a dispersed instruction from the 
server computer and operating on the copy of the conference model data 
according to the instruction received from the server computer. 
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S X cnfer.ncin, system as ol.I_* in =!•'■ ' herein each client 
8. a conteicu >s ^ n , r v for viewing the 

computer (32A. 32B, 32C) further composes means (36C) 

conference model data. 

9 A P e«„.l conference ay— co„priain 9 « 1«« — *«. 

conn.ct.d for conviction; each co-puter 

conference model data (60); 

means (36B, for creating an instruction for operating on the 
con j: model data and sending the instruction to another computer, 

means (36A, 60) for operating on the conference model data 
according to an instruction; 

characterised by: 

one of the computers is a server computer (30) and the other 
computer or computers (32A. 32B. 32C) are client computers, each havxng a 
connection to the server computer; 

the server computer (30) further comprises a means (SOB) for 
dispersing a received instruction to all the connected client computers 
(32A, 32B, 32C); and 

the means (36A, 60) for operating comprises means for receiving a 
dispersed instruction from the server computer; 

whereby a sequence of operating instructions (64B) from different 
computers in the personal conferencing system will be performed in the 
same order on each copy of conference model data (60). 

10. A personal conferencing system comprising: 

a server object and a plurality of client objects; 

a model object (3 6A) having model data (60) and means (62) for 
operating on the model data (60) to an instruction message (64B); 

each client object (36) having means (36B) for creating an. 
instruction for operating on the model object (36A) ; 
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characterised by: 

each client object (36) comprising an associated model object 

(36A) ; 

5 

each client object (36) further comprises means (36B) for passing 
an operating instruction to the server object; 

said server object (50) further comprises means (SOB) for 
10 dispersing a passed instruction from the server object to all client 

objects (36) ; 

thereby allowing a sequence of instructions from different client 
objects (3 6) to be performed in the same order by each model object on 
15 each instance of the model data (60). 

11. A personal conferencing system as claimed in claim 10 further 
comprising a means for packaging a client object and a model object for 
transmission across a computer network. 

20 

12. A personal conferencing system as claimed in claim 11 wherein the 
model object (36A) further comprising means for causing a model object to 
generate a state message containing the current model data (60) and pass 
the state message to another object. 

13. A personal conferencing system as claimed in claim 12 wherein the 
model object further comprises means for causing a model object to set 
its model data to that passed in a state message whereby one model object 
can be copied with another model object. 

14. A personal conferencing system as claimed in claims 10,11,12 or 13 
serving further comprising a centralised model object associated with the 
server object. 

35 15. A personal conferencing system as claimed in claim 14 wherein a 

model object associated with a client object is copied from the model 
object associated with the server object. 
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16. A personal conferencing system as claimed in any of claims 10 to 15 
wherein the classes and objects are implemented in a hosted machine byte 
code . 



# 
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17 A personal conferencing system as claimed in claim 16 wherein the 
client class and the model class comprise a hosted machine byte code 
applet downloadable and executable by a network browser enabled for the 
hosted machine byte code. 





P&tent 
Office 



Application No: 
Claims searched: 



GB 9707316.7 
1 - 17 



Examiner: 
Date of search: 



Paul Nicholls 
12 June 1997 



Patents Act 1977 

Search Report under Section 17 

Databases searched: 



UK Patent Office collections, including GB, EP, WO & US patent specifications, in: 
UK CI (Ed.O): G4A (APX, AUXX) 
lnt CI (Ed. 6): G06F 9/46, 17/60 
Other: Online: WPI 



Documents considered to be relevant: 



Category 



Identity of document and relevant passage 



Relevant 
to claims 



X 



X 

X 
X 



GB 2,281,423 A (HEWLETT-PACKARD) - See Fig 1 



EP 0,657,833 A2 (IBM) - See Fig 1 



EP 0.645,726 A2 (AT&T) - See Fig 5 

EP 0,645,725 A2 (AT&T) - See Fig 5 

EP 0,558,006 A2 (TOYOTA) - See Fig 1 

EP 0,319,232 A2 (XEROX) - See page 11 lines 37-40 

WO 96/12241 Al (HAND HELD PRODUCTS) - See page 21 andFig 

4B 

WO 94/1 1806 Al (BRIGHAM YOUNG UNIVERSITY) - See page 4 

US 5,392,400 A (BERKOWITZ et al) - Whole document 



1, 2. 7, 9, 
10 at least 

1 . 2, 7. 9, 
10 at least 

1.2.7. 9, 
10 at least 

I, 2, 7. 9. 
10 at least 

1,2,7. 9, 
10 at least 

1. 2, 7. 9, 
10 at least 

1, 2. 7. 9, 
1 0 at least 

1, 2, 7, 9, 
10 at least 

1, 2, 7, 9, 
10 at least 



X Document indicating lack of novelty or inventive step A Document indicating technological background and/or state of the an. 

Y Document indicating lack of inventive step if combined P Document published on or after the declared priority date but before 

with one or more other documents of same category. the filing date of this invention. 

£ Patent document published on or after, but with priority date earlier 

& Member of the same patent family than, the filing date of this application. 



An Executive Agency of the Department of Trade and Industry 




# 



R»cent 
Office 




Application No: 
Claims searched: 



GB 9707316.7 
1 - 17 



Examiner: 
Date of search: 



Paul Nicholls 
12 June 1997 



Category 


Identity of document and relevant passage 


Relevant 
to claims 


X 
X 


US 5,319,777 A (PEREZ) - See Fig 12 

US 5,293,619 A (DEAN) - Whole document 


1 , 2, 7. 9, 
10 at least 

1, 2, 7, 9, 
10 at least 



X Document indicating lack of novelty or inventive step A 
V Document indicating lack of inventive step if combined P 
with one or more other documents of same category. 

E 

Member of the same patent family 



Document indicating technological background and/or state of the an. 
Document published on or after the declared priority date but before 
the filing date of this invention. 

Patent document published on or after, but with priority date earlier 
than, the filing date of this application. 



An Executive Agency of the Department of Trade and Industry 



ft 



•RLD INTELLECTUAL PROPERTY ORGAMZA 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 
G09B 5/14, 7/04 



A3 



(11) International Publication Number: WO 98/03953 

(43) International Publication Date: 29 January 1998 (29.01.98) 



(21) International Application Number: PCT/CA97/00526 

(22) International Filing Date: 23 July 1997 (23.07.97) 



(30) Priority Data: 

08/681,418 



23 July 1996 (23.07.96) 



US 



(60) Parent Application or Grant 

(63) Related by Continuation 
US 

Filed on 



08/681.418 (CIP) 
23 July 1996 (23.07.96) 



(71) Applicant (for all designated States except US): AVALON 

INFORMATION TECHNOLOGIES INC. [CA/CAJ; One 
Kenview Boulevard, Brampton, Ontario L6T 5E6 (CA). 

(72) Inventor; and 

(75) Inventor/Applicant (for US only): SIMMONS. Dale [CA/CAJ; 
709 Indian Road, Toronto, Ontario M6P 2C4 (CA). 

(74) Agent: DEETH WILLIAMS WALL; National Bank Building, 
Suite 400, 150 York Street, Toronto, Ontario M5H 3S5 
(CA). 



(81) Designated States: AL, AM, AT, AU, AZ, BA. BB, BG, BR. 
BY. CA, CH, CN. CU, CZ. DE, DK, EE, ES, Fl, GB, GE. 
GH, HU, IL, IS, JP, KE, KG, KP. KR. KZ, LC, LK, LR, 
LS. LT, LU, LV. MD, MG. MK, MN, MW, MX, NO, NZ, 
PL. PT. RO, RU. SD. SE. SG, SI. SK, SL. TJ. TM, TR, 
TT, UA. UG, US, UZ, VN, YU, ZW, ARIPO patent (GH, 
KE, LS, MW, SD, SZ, UG. ZW), Eurasian patent (AM, AZ. 
BY, KG, KZ. MD, RU, TJ, TM), European patent (AT. BE. 
CH, DE, DK, ES, Fl. FR. GB, GR, IE, IT. LU. MC. NL. 
PT, SE). OAPI patent (BF, BJ, CF, CG, CI, CM. GA. GN, 
ML, MR, NE, SN, TD, TG). 



Published 

With international search report. 

Be/ore the expiration of the time limit for amending the claims 
and to he republished in the event of the receipt of amendments. 

(88) Date of publication of tbe international search report: 

26 February 1998 (26.02.98) 



(54) Title: METHOD OF INTERACTIVE COMPUTER BASED INSTRUCTION 



(57) Abstract 



This invention relates to a method of combining interactive instruction over a computer network with distributed course materials 
for the provision of computer- based training to a geographically dispersed group of students. A method is disclosed for combining on-line 
transmission of audio or video instruction and related data with distributed training software and data to reduce the cost and increase 
the effectiveness of computer-based instruction. The present invention also discloses methods for providing immediate feedback from the 
students to the instructor and methods for enabling each student to record and replay all or part of the training session and to re-use the 
training materials in a variety of ways which provide continuing training benefits. During on-line sessions, commands from the instructor's 
workstation station direct each student workstation to retrieve the desired data from the storage medium and display it on the student's screen. 
Compressed audio, consisting of the instructor's commentary and student comments, command data and screen interaction information may 
be transmitted over ordinary telephone lines. Each student's workstation is able to display the full multimedia training session, consisting of 
full-motion video, real-time audio, photos, graphics, text and real-time annotations and commentary from the instructor and other students, 
by combining the locally-stored multimedia presentation and the interactive, real-time data. 




FOR THE PURPOSES OF INFORMATION ONLY 
Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


St 


Slovenia 


AM 


Armenia 


Fl 


Finland 


LT 


Lithuania 


SK 


Slovakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


(*A 


Gabon 


LV 


Latvia 


SZ 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


Gil 


Ghana 


MC 


Madagascar 


TJ 


Tajikistan 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


TR 


Turkey 


BC 


Bulgaria 


HU 


Hungary 


ML 


Mali 


TT 


Trinidad and Tobago 


BJ 


Dentn 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


II, 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mex ico 


UZ 


Uzbekistan 


CK 


Central African Republic 


JP 


Japan 


NF 


Niger 


VN 


Viet Nam 


CO 


Congo 


KE 


Kenya 


NL 


Netherlands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZYV 


Zimbabwe 


CI 


C6te d'lvoire 


KP 


Democratic People's 


NZ 


New Zealand 






CM 


Cameroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


FT 


Portugal 






CU 


Cuba 


KZ 


Kazakatan 


RO 


Romania 






CZ 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DK 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






KK 


Estonia 


LR 


Liberia 


SO 


Singapore 







This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 



III GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHD3IT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLURRED OR BLLEGIBLE TEXT OR DRAWING 



□ SKEWED/SLANTED IMAGES 



COLOR OR BLACK AND WHITE PHOTOGRAPHS 



